📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/DataContractRepository.java

In mergeContracts(), semantic rules from the data product are skipped if an entity rule has the same name, using entityRuleNames.contains(dpRule.getName()). However, this only checks the rule name, not the rule content or logic.

If an entity has a rule named "DataQuality" with one definition, and the data product has a rule named "DataQuality" with a different definition, the entity's rule wins entirely. This may be the intended behavior (as stated in the PR - "asset rules take precedence"), but there's no way to detect or warn about this conflict.

Consider logging when a rule name collision is detected so administrators can understand why certain data product rules aren't being applied.

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/DataContractRepository.java:655

The getEffectiveDataContract() method checks if an entity belongs to multiple Data Products and skips inheritance:

if (dataProducts.size() > 1) {
  LOG.debug(
      "Entity {} belongs to {} data products. Skipping contract inheritance to avoid ambiguity.",
      entity.getId(),
      dataProducts.size());
  return entityContract;
}

If an asset is being added to a second Data Product while another request is computing the effective contract, there could be a race condition where:

1. Thread A checks: asset has 1 DP → proceeds with inheritance
2. Thread B adds asset to second DP
3. Thread A returns inherited contract from DP1

This is likely acceptable since the next request will see the correct state, but it could lead to brief inconsistency. Consider documenting this eventual consistency behavior in the API documentation.

📄 openmetadata-service/src/main/java/org/openmetadata/service/apps/bundles/dataContracts/DataContractValidationApp.java:143

In processDataProductContracts(), for each asset in a Data Product, the code makes multiple database calls:

1. Entity.getEntity() to fetch the full asset
2. contractRepository.getEntityDataContractSafely(asset) to check for existing contract
3. contractRepository.materializeInheritedContract() to create new contract
4. contractRepository.getEffectiveDataContract(asset) which again fetches contracts

When processing many assets (pagination is set to 100 per batch), this could result in significant database load. Consider:

1. Batching the initial contract existence checks
2. Caching the Data Product contract instead of potentially re-fetching it in getEffectiveDataContract
3. Using a single transaction for materialization and validation per batch

This is acceptable for the scheduled app execution but could become problematic with large Data Products containing thousands of assets.

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/DataContractRepository.java:663

In getEffectiveDataContract(), the code only inherits from Data Product contracts that are APPROVED:

if (dataProductContract != null
    && dataProductContract.getEntityStatus() != EntityStatus.APPROVED) {
  dataProductContract = null;
}

This is good defensive logic, but there's no logging or indication to users when inheritance doesn't happen due to non-approved status. Consider adding a debug log statement when a DP contract exists but isn't inherited due to its status. This would help with debugging when users expect inheritance but don't see it happening.

Also, if the Data Product contract is in IN_REVIEW status, users might expect some visibility into pending contract changes that will eventually be inherited.

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/DataContractRepository.java:1227 📄 openmetadata-ui/src/main/resources/ui/src/locale/languages/en-us.json:2388
The backend error message in preDelete() is different from the i18n message added in locale files:

Backend (DataContractRepository.java):

throw BadRequestException.of(
    "Cannot delete an inherited data contract. The contract is inherited from a Data Product "
        + "and can only be removed by removing the entity from the Data Product or by creating "
        + "an entity-specific contract that overrides the inherited one.");

Locale files (en-us.json):

"inherited-contract-cannot-be-deleted": "Inherited contracts cannot be deleted. Remove the entity from the Data Product or create an entity-specific contract."

The backend message mentions "overrides the inherited one" while the locale message doesn't mention overriding. Consider aligning these messages for consistency. The locale message is also used in the frontend for user-facing errors, so users may see different messages depending on where the error originates.

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/DataContractRepository.java:685
In inheritFromDataProductContract(), after using JsonUtils.deepCopy, the code calls setInherited(true) on various objects. While the outer null checks exist for most fields, the pattern is inconsistent:

// This is correct - checks before calling
if (inherited.getTermsOfUse() != null) {
  inherited.getTermsOfUse().setInherited(true);
}

However, the semantic rules loop doesn't check if inherited.getSemantics() is non-null before iterating:

// Line 712 - needs null check before loop
if (inherited.getSemantics() != null) {
  for (SemanticsRule rule : inherited.getSemantics()) {
    rule.setInherited(true);
  }
}

The code does have this check, so it's actually correct. After re-reading, all null checks appear to be in place. Disregard this finding - the code is correct.

📄 openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/DataContractRepository.java:766
In validateContractWithEffective(), schema validation is performed using effectiveContract.getEntity():

if (effectiveContract.getSchema() != null && !effectiveContract.getSchema().isEmpty()) {
  SchemaValidation schemaValidation =
      validateSchemaFieldsAgainstEntity(effectiveContract, effectiveContract.getEntity());
  result.withSchemaValidation(schemaValidation);
}

However, in inheritFromDataProductContract(), the inherited contract's entity reference is updated to point to the actual entity (the asset), not the Data Product:

inherited.setEntity(entity.getEntityReference());

But the schema is cleared for inherited contracts:

inherited.setSchema(null);

This means the schema validation block won't execute for purely inherited contracts (which is correct). However, in mergeContracts(), schema is NOT inherited from the Data Product contract, so merged contracts will only have the entity's schema. The code appears correct, but the function name validateContractWithEffective is slightly misleading since it doesn't use contractForResults.getEntity() for validation - it uses effectiveContract.getEntity().

After more analysis: The code is functionally correct. The effective contract's entity reference is set to the actual asset, so schema validation runs against the right entity. This finding is a false positive.

📄 openmetadata-service/src/main/java/org/openmetadata/service/apps/bundles/dataContracts/DataContractValidationApp.java:173-174
In processDataProductContracts(), assets are retrieved with a hardcoded limit of 1000:

ResultList<EntityReference> assetsResult =
    dataProductRepository.getDataProductAssets(dataProduct.getId(), 1000, 0);

This does not handle pagination if a Data Product has more than 1000 assets. Assets beyond the first 1000 will be silently skipped during contract validation.

Suggested fix:
Implement pagination to process all assets, similar to the pagination used in validateExistingContracts().

📄 openmetadata-ui/src/main/resources/ui/src/components/DataContract/ContractTermOfService/ContractTermsOfService.component.tsx:53-56
In ContractTermsOfService.component.tsx, the handleContentOnChange function uses unsafe type casting:

const handleContentOnChange = (value: string) => {
  // Always save in the new object format
  onChange({
    termsOfUse: { content: value } as unknown as string,
  });
};

This as unknown as string bypasses TypeScript's type checking completely. If the DataContract type has been updated to expect TermsOfUse object for termsOfUse, the type definition should be updated to reflect this, rather than using dangerous casts.

Impact: This could lead to runtime errors or unexpected behavior if the upstream code expects a different type.

Suggested fix:
Update the DataContract type definition to properly reflect the new termsOfUse structure, or use proper type guards.